## Summary

This PR fixes the performance regression where `@fastmath x^2` for
`Float32` was not being inlined to efficient LLVM code, unlike
`Float64`.

## Problem

As reported in #60639, `@fastmath x^2` for `Float32` was falling back to
`power_by_squaring` instead of using the LLVM `powi` intrinsic. This
resulted in:
- Unnecessary function calls instead of inline multiplication
- Potential type promotion to `Float64`
- Suboptimal generated code compared to `Float64`

Before this fix, `@code_llvm @fastmath Float32(1.5)^2` would show calls
to `power_by_squaring`, while `Float64` correctly used the `llvm.powi`
intrinsic.

## Solution

Added the missing `pow_fast` methods for `Float32` and `Float16`:

- `pow_fast(::Float32, ::Int32)` - uses `llvm.powi.f32.i32` intrinsic
directly
- `pow_fast(::Float32, ::Integer)` - wrapper that converts to `Int32`
when safe, matching the `Float64` pattern
- `pow_fast(::Float16, ::Integer)` - converts to `Float32`, computes,
and converts back

This mirrors the existing implementation for `Float64` which already
used `llvm.powi.f64.i32`.

## Testing

Added a regression test that verifies `@fastmath x^2` generates inline
`fmul` instructions (not `power_by_squaring` calls) for `Float16`,
`Float32`, and `Float64`.

Fixes #60639

---------

Co-authored-by: Oscar Smith <[email protected]>
(cherry picked from commit f34d5f2)